DR. AJAY KUMAR PATHAK
ASSISTANT PROFESSOR
Copyright © by Dr. Ajay kumar pathak
B. Sc IT SEMESTER 5 NOTES BASED ON NEP
SUBJECT : MJ–11 (Th): SOFTWARE ENGINEERING
NOTES OF MJ–11 (Th): SOFTWARE ENGINEERING
Course Objectives:
OBJECTIVES: THE OBJECTIVE OF
THE COURSE IS TO ENABLE STUDENTS –
·
To understand the
Software Engineering Practice and the Software Engineering Process Models
·
To understand
Design Engineering, Web applications
·
To gain knowledge
of the software testing
·
To understand
Software Project Management
UNIT- 2 :- REQUIREMENT ENGINEERING PROCESS
REQUIREMENT
ENGINEERING PROCESS:-
The process to gather the
software requirements from client, analyze and document them is known as
requirement engineering. The goal of requirement engineering is to develop and
maintain sophisticated and descriptive System Requirements Specification document.
Requirements Engineering is a systematic approach to defining, documenting, and
managing requirements throughout the Requirements Engineering Lifecycle. It
forms the foundation of successful software and systems development by ensuring
that stakeholder needs are clearly understood, prioritized, and translated into
actionable deliverables.
This process is critical
because poorly defined requirements often lead to costly project delays,
rework, and unmet expectations. With the right Requirements Software Solutions,
and Tools, organizations can streamline the complete Engineering Process,
reduce risks, and ensure alignment across teams.
Requirement
Engineering Process:-
It is a five step process
(1) Requirements elicitation
(2) Feasibility Study
(3) Requirements management
(4) Requirements specification (NOT IN
SYLLABUS)
(5) Requirements for verification and
validation (NOT IN SYLLABUS)
(1) REQUIREMENTS ELICITATION (Gathering
Needs & Expectations):-
It is related to the various
ways used to gain knowledge about the project domain and requirements. The
various sources of domain knowledge include customers, business manuals, the
existing software of the same type, standards, and other stakeholders of the
project. The techniques used for requirements elicitation include interviews,
brainstorming, task analysis, Delphi technique, prototyping, etc. Some of these
are discussed here. Elicitation does not produce formal models of the
requirements understood. Instead, it widens the domain knowledge of the analyst
and thus helps in providing input to the next stage.
Requirements elicitation is the
process of gathering information about the needs and expectations of
stakeholders for a software system. This is the first step in the requirements
engineering process and it is critical to the success of the software
development project. The goal of this step is to understand the problem that
the software system is intended to solve and the needs and expectations of the
stakeholders who will use the system.
Several techniques
can be used to elicit requirements, including:-
(a) Questionnaires:- A document with pre-defined set of objective questions
and respective options is handed over to all stakeholders to answer, which are
collected and compiled
(b) Interviews:- These are one-on-one conversations with stakeholders
to gather information about their needs and expectations.
(c ) Surveys:- These are questionnaires that
are distributed to stakeholders to gather information about their needs and
expectations.
(d) Focus Groups:- These are small groups of stakeholders who are
brought together to discuss their needs and expectations for the software
system.
(e) Observation:- This technique involves observing the stakeholders in
their work environment to gather information about their needs and
expectations.
(f) Prototyping:- This technique involves creating a working model of
the software system, which can be used to gather feedback from stakeholders and
to validate requirements.
(2) FEASIBILITY STUDY:-
The feasibility study mainly
concentrates on below mentioned areas below. Among these Economic Feasibility
Study is the most important part of the feasibility analysis and the Legal
Feasibility Study is less considered feasibility analysis.
(a) Technical Feasibility:- In Technical Feasibility current resources both
hardware software along required technology are analyzed / assessed to develop
the project. This technical feasibility study reports whether there are correct
required resources and technologies that will be used for project development.
Along with this, the feasibility study also analyzes the technical skills and
capabilities of the technical team, whether existing technology can be used or
not, whether maintenance and up-gradation are easy or not for the chosen
technology, etc.
(b) Operational Feasibility:- In Operational Feasibility degree of providing
service to requirements is analyzed along with how easy the product will be to
operate and maintain after deployment. Determining suggested solution by the
software development team is acceptable or not, etc.
(c ) Schedule Feasibility:- In schedule feasibility, the project timeline is
evaluated to determine if it is realistic and achievable. Significant
milestones are identified, and deadlines are established to track progress
effectively. Resource availability is assessed to ensure that the necessary
resources are accessible to meet the project schedule.
(d) Legal Feasibility:- In legal feasibility, the project is ensured to
fulfill with all relevant laws, regulations, and standards. It identifies any
legal constraints that could impact the project and reviews existing contracts
and agreements to assess their effect on the project's execution. Additionally,
legal feasibility considers issues related to intellectual property, such as
patents and copyrights, to safeguard the project's innovation and originality.
(e) Economic Feasibility:- In the Economic Feasibility study cost and benefit of
the project are analyzed. This means under this feasibility study a detailed
analysis is carried out will be cost of the project for development which includes
all required costs for final development hardware and software resources
required, design and development costs operational costs, and so on.
(3) REQUIREMENTS MANAGEMENT:-
Requirement management is the
process of analyzing, documenting, tracking, prioritizing, and agreeing on the
requirement and controlling the communication with relevant stakeholders. This
stage takes care of the changing nature of requirements. It should be ensured
that the SRS is as modifiable as possible to incorporate changes in
requirements specified by the end users at later stages too. Modifying the
software as per requirements in a systematic and controlled manner is an
extremely important part of the requirements engineering process.
Requirements management is the
process of managing the requirements throughout the software development life
cycle, including tracking and controlling changes, and ensuring that the
requirements are still valid and relevant. The goal of requirements management
is to ensure that the software system being developed meets the needs and
expectations of the stakeholders and that it is developed on time, within
budget, and to the required quality.
Several key
activities are involved in requirements management:-
(a) Tracking and controlling changes:- This involves monitoring and controlling
changes to the requirements throughout the development process, including
identifying the source of the change, assessing the impact of the change, and
approving or rejecting the change.
(b) Version control:- This involves
keeping track of different versions of the requirements document and other
related artifacts.
( c) Traceability: This involves linking the requirements to other
elements of the development process, such as design, testing, and validation.
(d) Communication:- This involves ensuring that the requirements are
communicated effectively to all stakeholders and that any changes or issues are
addressed promptly.
(e) Monitoring and reporting:- This involves monitoring the progress of the
development process and reporting on the status of the requirements.
(4) REQUIREMENTS SPECIFICATION (NOT IN
SYLLABUS) :-
This activity is used to
produce formal software requirement models. All the requirements including the
functional as well as the non-functional requirements and the constraints are
specified by these models in totality. During specification, more knowledge
about the problem may be required which can again trigger the elicitation
process. The models used at this stage include ER diagrams, data flow diagrams(DFDs),
function decomposition diagrams(FDDs), data dictionaries, etc. Requirements specification is the process of
documenting the requirements identified in the analysis step in a clear,
consistent, and unambiguous manner. This step also involves prioritizing and
grouping the requirements into manageable chunks.
The goal of this step is to
create a clear and comprehensive document that describes the requirements for
the software system. This document should be understandable by both the
development team and the stakeholders.
Several types of
requirements are:-
(a) Functional Requirements:- These describe what the software system should do.
They specify the functionality that the system must provide, such as input
validation, data storage, and user interface.
(b) Non-Functional Requirements:- These describe how well the software system
should do it. They specify the quality attributes of the system, such as
performance, reliability, usability, and security.
(c ) Constraints:- These describe any limitations or restrictions that
must be considered when developing the software system.
(d) Acceptance Criteria:- These describe the conditions that must be met for
the software system to be considered complete and ready for release.
(5) REQUIREMENTS FOR VERIFICATION AND
VALIDATION (NOT IN SYLLABUS):-
Verification:- It refers to the set of tasks that
ensures that the software correctly implements a specific function.
Validation:- It refers to a different set of tasks
that ensures that the software that has been built is traceable to customer
requirements. If requirements are not validated, errors in the requirement
definitions would propagate to the successive stages resulting in a lot of
modification and rework.
The main steps for
this process include:-
(a) The requirements should be consistent
with all the other requirements i.e. no two requirements should conflict with
each other.
(b) The requirements should be complete in every sense.
( c) The requirements should be practically achievable.
ADVANTAGES OF
REQUIREMENTS ENGINEERING PROCESS
1. Helps ensure that the software being developed meets
the needs and expectations of the stakeholders
2. Can help identify potential issues or problems early
in the development process, allowing for adjustments to be made before
significant
3. Helps ensure that the software is developed in a
cost-effective and efficient manner
4. Can improve communication and collaboration between
the development team and stakeholders
5. Helps to ensure that the software system meets the
needs of all stakeholders.
6. Provides an unambiguous description of the
requirements, which helps to reduce misunderstandings and errors.
7. Helps to identify potential conflicts and
contradictions in the requirements, which can be resolved before the software
development process begins.
8. Helps to ensure that the software system is delivered
on time, within budget, and to the required quality standards.
9. Provides a solid foundation for the development
process, which helps to reduce the risk of failure.
Disadvantages of
Requirements Engineering Process
1. Can be time-consuming and costly, particularly if the
requirements-gathering process is not well-managed
2. Can be difficult to ensure that all stakeholders'
needs and expectations are taken into account
3. It Can be challenging to ensure that the requirements
are clear, consistent, and complete
4. Changes in requirements can lead to delays and
increased costs in the development process.
5. As a best practice, Requirements engineering should be
flexible, adaptable, and should be aligned with the overall project goals.
6. It can be time-consuming and expensive, especially if
the requirements are complex.
7. It can be difficult to elicit requirements from
stakeholders who have different needs and priorities.
8. Requirements may change over time, which can result in
delays and additional costs.
9. There may be conflicts between stakeholders, which can
be difficult to resolve.
10. It may be challenging to ensure that all stakeholders
understand and agree on the requirements.
REQUIREMENT ANALYSIS
IN SOFTWARE DEVELOPMENT:-
Requirement analysis is a
foundational step in software development that focuses on identifying and
documenting the needs of stakeholders. It serves as the blueprint for the
entire development process, ensuring that the final software product meets user
expectations and business goals.
During this phase, both
functional and non-functional requirements are collected through communication
with clients, users, and other stakeholders. A thorough and clear requirement
analysis minimizes the risks of miscommunication, reduces costly changes later
in the project, and sets the stage for efficient design and development.
Requirement Analysis
Techniques:-
(i) Data Flow Diagrams (DFD):- Data Flow Diagrams visually represent the flow of
data within a system. They help to understand how data moves between different
processes, stores, and external entities, making it clear how each part of the
system interacts.
Example: In a banking application,
a DFD can show how a user submits a withdrawal request, how the system checks
the account balance, and how data is returned to the user.
(ii) Entity-Relationship Diagrams (ERD):- ERDs are used to represent the relationships between
data entities in a system. This is essential for database design and
understanding how different pieces of data interact with each other.
Example: In an e-commerce app,
an ERD would show relationships between “Customers,” “Orders,” “Products,” and
“Payments.”
(iii) Unified Modeling Language (UML):- UML is a standardized modeling language that provides
a set of diagrams for visualizing the design of a system. It includes class
diagrams, sequence diagrams, and use case diagrams, which help define both the
static and dynamic aspects of a system.
Example: A UML use case diagram
can represent the interactions between a user and the system, like “Search for
products” or “Place an order.”
(iv) Prototyping Tools:- Prototyping tools (like Figma, Adobe XD, or Sketch)
allow analysts to create interactive prototypes that simulate the user
interface (UI) of the system. These prototypes help stakeholders visualize the
app’s user experience (UX) and refine requirements based on feedback.
Example: Using Figma to create
a clickable prototype of a mobile app to gather feedback from users on the
design and user flows.
(v) State Diagrams:- State diagrams (or state machine diagrams) represent
how the system or object transitions between various states based on events or
conditions. This technique is particularly useful for systems with complex
states, such as workflow applications or control systems. Example: A state
diagram for an order processing system might show states like “Order Placed,”
“Order Confirmed,” “Payment Pending,” and “Shipped.”
(vi) Flowcharts:- Flowcharts are used to map out the step-by-step
sequence of processes and decisions in the system. They help ensure clarity
around logic and operations, identifying potential bottlenecks or errors.
Example: A flowchart to represent the process of user registration for a web
app, including decision points for valid/invalid email or password format.
REQUIREMENT
ENGINEERING PROCESS DOCUMENTATION:-
Requirement documentation in software
engineering is the systematic process of documenting all necessary information
related to a software project's requirements. It serves as a single source of
truth for project stakeholders, including product managers, software testers,
and developers. Investing in requirement documentation is a good practice for
ensuring project success.
Key components include:-
(i) Software Requirements Document (SRD):- The foundation of requirement documentation, the SRD
outlines functional requirements, non-functional requirements, and external
components necessary for the software's functionality and performance.
(ii) Software Requirements Specification
(SRS) Document:- An elaboration of the
SRD, the SRS document provides a detailed breakdown of requirements, often
including diagrams, code snippets, and acronyms for clarity and precision.
(iii) Project Stakeholders:- Vital contributors to requirement documentation,
including product managers, developers, testers, and key stakeholders from
client organizations.
(iv) Process Documentation:- Describes the methodology for eliciting (Gathering
Needs & Expectations), analyzing, and validating requirements, ensuring a
smart, efficient approach to software development.
(v) External Interface Requirements:- Specifies the interactions between the software
system and external components, such as APIs, databases, or third-party
services.
(vi) Test Automation Tutorials:- Guides
automated testing techniques to ensure software quality and reliability.
INFORMATION
MODELING:-
An information model in
software engineering is a representation of concepts and the relationships,
constraints, rules, and operations to specify data semantics for a chosen
domain of discourse. Information Modeling is a systematic technique used in
software engineering to identify, analyze, organize, and represent information
(data) required by a system. It focuses on what data the system needs, how data
elements are related, and the rules (constraints) governing the data,
independent of how the system will be implemented. It is mainly used during the
requirements analysis and design phase to create a clear structure of data
before coding begins.
Within the field of software
engineering and data modeling, an information model is usually an
abstract, formal representation of entity types that may include their
properties, relationships and the operations that can be performed on them. The
entity types in the model may be kinds of real-world objects, such as devices
in a network, or occurrences, or they may themselves be abstract, such as for
the entities used in a billing system. Typically, they are used to model a
constrained domain that can be described by a closed set of entity types,
properties, relationships and operations.
Basically the information
modeling is very important because it’s Helps in understanding user requirements clearly, Avoids data redundancy and inconsistency, Improves
database design, Makes system easy to maintain and scalable, Acts as
a communication tool between
developers, analysts, and stakeholders
Example:- Consider a College Management System.
The system needs to store
information about:
ü Students
ü Courses
ü Teachers
ü Enrollment
Information
modeling helps us:
ü Decide what
data to store
ü Define relationships
(which student studies which course)
ü Set rules
(one student can enroll in many courses)
MAIN TECHNIQUES USED IN INFORMATION MODELING:-
(1) Data Flow Diagrams
(2) Entity–Relationship (ER) Model or Entity
Relationship Diagrams
(3) Designing the architecture.
(4) UML Class Diagram (NOT IN SYLLABUS)
(5) Data Dictionary (NOT IN SYLLABUS)
DATA FLOW DIAGRAMS:-
DFD provides the functional
overview of a system. The graphical representation easily overcomes any gap
between ’user and system analyst’ and ‘analyst and system designer’ in
understanding a system. Starting from an overview of the system it explores
detailed design of a system through a hierarchy. DFD shows the external
entities from which data flows into the process and also the other flows of
data within a system. It also includes the transformations of data flow by the
process and the data stores to read or write a data.
DFDs are important because they
help you visualize how data moves through your system, spot inefficiencies, and
find opportunities to improve overall functionality. This leads to more
efficient operations, better decision-making, and enhanced communication among
team members.
Graphical notations for Data
Flow Diagram, There are four basic symbols that are used to represent a
data-flow diagram:-
(1) External Entity:- External
entity also known as Terminator, Actor, is the component of Data flow Diagram
(DFD) that stands outside of the system and communicates with the system. It
can be, for example, organizations like banks, groups of people like customers
or different departments of the same organization, which is not a part of the
model system and is an external entity. Modeled systems also communicate with
terminator.
(2) Process:- Input to output transformation in a system takes place because of
process function. The symbols of a process are rectangular with rounded
corners, oval, rectangle or a circle. The process is named a short sentence, in
one word or a phrase to express its essence
(3) Data Store (Warehouse):- The data is stored in the warehouse for later use.
Two horizontal lines represent the symbol of the store. The warehouse is simply
not restricted to being a data file rather it can be anything like a folder
with documents, an optical disc, a filing cabinet. The data warehouse can be
viewed independent of its implementation. When the data flow from the warehouse
it is considered as data reading and when data flows to the warehouse it is
called data entry or data updating.
(4) Data Flow:- Data flow
describes the information transferring between different parts of the systems.
The arrow symbol is the symbol of data flow. A relatable name should be given
to the flow to determine the information which is being moved. Data flow also
represents material along with information that is being moved. Material shifts
are modeled in systems that are not merely informative. A given flow should
only transfer a single type of information. The direction of flow is
represented by the arrow which can also be bi-directional.
QUESTION:- MAKE A DFD
OF LIBRARY MANAGEMENT FOR THE BOOKS ISSUES
TYPES OF DATA FLOW
DIAGRAMS:-
(1) Logical data flow diagram (2) Physical
data flow diagram
(1) Logical data flow diagrams:-
The Logical Data Flow Diagram mainly focuses on the system process. It
illustrates how data flows in the system. Logical Data Flow Diagram (DFD)
mainly focuses on high level processes and data flow without diving deep into
technical implementation details. Logical DFDs is used in various organizations
for the smooth running of system. Like in a Banking software system, it is used
to describe how data is moved from one entity to another.
(2) Physical data flow diagram or Physical DFD:- Physical data flow diagram shows how the
data flow is actually implemented in the system. In the Physical Data Flow
Diagram (DFD), we include additional details such as data storage, data
transmission, and specific technology or system components including.
ü Hardware, Software, Databases, File structures, Actual data movement and storage mechanisms
DATA FLOW DIAGRAM
LEVELS:-
Data flow diagrams are
structured in layers, with each layer providing more details about the system’s
processes or data flow. These layers typically range from Level 0 to Level 2,
with some systems extending to Level 3 for deeper complexity.
The number of layers you add to
your diagram depends on how detailed you want your diagram to be.
(1) Data flow diagram Level 0:- Level 0 is usually the context level of a data flow diagram. At this level, the diagram gives a basic overview of the entire
system without focusing on specific parts. Think of Level 0 as the starting
point for understanding the system at a high level. It identifies the main
processes and their interactions. This type of diagram is great for helping
stakeholders and team members grasp the system's scope and its primary inputs
and outputs without overwhelming them.
(2) Data flow diagram Level 1:- At Level 1, things get more
detailed, with the diagram breaking down Level 0’s high-level processes into
more specific functions. Basically, it maps out the flow of data between
processes and identifies the main functions that drive the system's operations.
This level of detail is important for understanding how data moves through different
stages of the system and how each process contributes to the overall workflow.
(3) Data flow diagram Level 2:- Level 2 joints deeper into the
processes outlined in Level 1, providing a detailed look at specific sections
of the system. This level of detail allows system designers and analysts to
uncover complex interactions and dependencies between processes — and it's
important for identifying the potential area, streamlining workflows, and
making sure data flows throughout the system smoothly.
EXAMPLE OF 0 LEVEL, 1
LEVEL AND 2 LEVEL ALL LEVELS USED FOR A RESERVATION
ENTITY RELATIONSHIP
DIAGRAMS:-
An entity relationship diagram
(ER diagram or ERD) is a visual representation of how items in a database
relate to each other. ERDs are a specialized type of flowchart that conveys the
relationship types between different entities within a system. They use a
defined set of symbols, including rectangles, ovals and diamonds, and link them
with connecting lines.
Within the relational model of
database design, ERDs establish how entries in a database are connected. ERDs
are a high-level conceptual data model that sets the stage for more advanced
database design and analysis.
EXAMPLE OF ERD
Symbols Used in ER
Diagram:-
(1) Entities (Rectangle):- Entities are
represented by rectangles, an object or
concept that you want to store information. There are two different entity
types as well.
Example:- Student, Teacher,
Book, Employee
Student is an entity because
each student exists independently and has data like roll number, name, etc.
(a) Strong entities:- are not dependent on any other entity within your
schema. It will be represented by a single rectangle and always has a primary
key.
(b) Weak entities (Double Rectangle):- are dependent
on a strong entity. In other words, without a relationship to a strong entity,
it would not exist. Also known as an identifying relationship, a weak entity is
depicted as a double rectangle.
Example:- Dependent (depends on
Employee), Order_Item (depends on Order)
Explanation:- Dependent cannot
exist without an Employee.
(2) Attribute (Oval):-
Ellipses (ovals) symbolize
attributes, detailing the properties and characteristics of entities. A key
attribute is the unique, distinguishing characteristic of the entity. A single
ellipse denotes a ‘simple attribute’, while a double ellipse (an ellipse within
an ellipse) highlights ‘multivalued attributes’ that can hold more than one
value.
For example, an entity like
Student will hold attributes such as Name and Courses. Here, while Name is a
single-value attribute, Courses can be multivalued if a student is enrolled in
multiple courses. Additionally, there are ‘derived attributes’ which are
calculated from other data points, such as Age being derived from the Date of
Birth.
(3) Relationship Symbols:- The interactivity between two entities is described
by a relationship which is visually represented as a diamond symbol. In the
case of a double diamond (a diamond within a diamond), this denotes a ‘weak
relationship’ which exists between a weak entity and its parent.
Relationships are the connected
lines linking the entities in an ERD together. They indicate how entities
within an ERD are associated with each other. If entities are nouns, and
attributes are adjectives, then relationships are verbs.
Entity participation in a
relationship might be total, in which case the entirety of the entity set is
involved in the relationship or partial. In partial participation, some or all
of the entities within the set might be involved in the relationship at any
specific time.
RELATIONSHIP
CARDINALITY or CARDINALITY TYPES:-
Cardinality is the quality of a
relationship that defines the number of instances in one entity that relate to
the instances of another.
(a) One-to-one relationships (1:1) indicate that a record within one entity might
only be referenced by one record in the other entity. The relationship between
the entities' universities and presidents is a one-to-one relationship because
every university has only one president. Conversely, each president is
responsible for exactly one university.
(b) One-to-many relationships (1:M) depict situations in which each record within
one entity relates to multiple records in another entity. There is a
one-to-many relationship between the entities universities and departments. A
university might have multiple departments, but each department is part of just
one university.
(c ) Many-to-many relationships (M:M) show that one or more records within both
entities can be connected. The entities students and professors have a
many-to-many relationship because just as one professor teaches a class with
many students, each student might also enroll in classes with other professors.
ERD DIAGRAM OF BANKING SYSTEM
ERD DIAGRAM OF RAILWAY RESERVATION SYSTEM
DESIGNING THE
ARCHITECTURE:-
The architecture of a system
describes its major components, their relationships (structures), and how they
interact with each other. Software architecture and design includes several
contributory factors such as Business strategy, quality attributes, human
dynamics, design, and IT environment. Software architecture refers to the
high-level structure of a software system, outlining its major components,
their relationships, and how they interact. It is a blueprint that guides the
system’s overall design and development, ensuring scalability, reliability, and
maintainability. This level of abstraction focuses on the “big picture,”
establishing the foundation on which all subsequent development is built.
Characteristics of
Software Architecture:-
1. Modularity – Breaking down a system into independent,
reusable components.
2. Scalability – Ensuring the system can handle growth
without major redesigns.
3. Security – Implementing best practices to protect data
and prevent breaches.
4. Performance – Optimising speed and resource usage for
efficiency.
5. Reliability – Ensuring minimal downtime and fault
tolerance.
6. Flexibility – Allowing easy modifications or
integrations with new technologies.
DIFFERENT TYPES OF
SOFTWARE ARCHITECTURE:-
1. Monolithic
Architecture:- In solid engineering, the
whole app framework works as an interconnected unit. All parts are coupled, and
they run on a lonely stage. It increases the effortlessness of improvement, as
the whole framework is held inside a lonely unit. System architecture modeling
in software engineering is also simpler to investigate and test. But the
absence of versatility, as the need might arise to be scaled is the problem.
2. Client-Server
Architecture:- In client-server engineering,
the framework is partitioned into two fundamental parts. Clients demand
services or data from servers, which gives the mentioned usefulness. It
increases adaptability, as servers can be added or moved up to deal with the
expanded burden. This design architecture in software engineering also brought
together data to the board and further developed security. But the weighty
server-side handling can prompt execution bottlenecks.
3. Service-Oriented
Architecture (SOA):- SOA is a building
style that attentions modularizing app frameworks into reusable services. The
importance of software architecture is stage autonomous. It usually imparts
through normalized conventions. It has the property of reusability and
interoperability of services. It also has versatility and adaptability in
coordinating new services.
ASSESSMENT:-
Assessment is the process of
evaluating, analyzing, and understanding a situation or problem to make correct
decisions. In software engineering,
assessment means Studying the current system, Identifying problems, risks, and
needs, Deciding what should be improved or developed.
Assessment is very Important
because to understand the real problem, to avoid wrong solutions, to ensure
correct planning, to reduce failure and cost
Example:- Suppose, a college
wants to develop an Online Attendance System.
Now the Assessment activities
are, Checking how attendance is
currently taken (manual register), Identifying problems (time-consuming,
errors, proxy attendance), Understanding user needs (teachers, students,
admin), Analyzing technical feasibility (internet, devices).
IMPACT OF REQUIREMENT
ENGINEERING IN THEIR PROBLEM:-
Requirement Engineering has a
huge impact on solving software problems correctly.
Impact 1:- Clear Understanding of the Problem
Without RE:- developers guess
the requirements
With RE :- developers understand the real needs
Example:- Problem: Hospital wants a “patient management
system”.
Without RE:- Developer builds
only patient registration
With RE:- System includes:-
Appointment booking, Doctor schedules, Medical history, Billing
Impact 2:- Reduction in
Errors and Rework
Good RE:- Reduces
misunderstandings, Avoids frequent changes, Saves time and money
Example:- Railway Ticket
Booking System
Without RE:- No seat availability
check, Users complain
With RE:- Requirements
include:- Real-time seat availability, Cancellation & refund, User
notifications
Impact 3:- Improves Communication Between Stakeholders
RE acts as a bridge between:- Clients,
Users, Developers, Testers
Example:- E-Commerce Website
RE ensures:- Customers want
easy checkout, Admin wants stock control, Owner wants sales reports, All needs
are documented clearly in SRS
Impact 4: Helps in Risk Identification
RE helps identify risks early.
Impact 5: Improves Software Quality,
When requirements are:- Clear,
Complete, Correct,
Then software becomes:- User-friendly, Reliable, Efficient
DECISION TABLES:-
In software testing, it’s
important to check how a system behaves with different inputs. A Decision Table
is a useful tool for organizing and managing these different combinations. A
Decision Table is a table that shows the relationship between inputs and rules,
cases, and test conditions. It's a very useful tool for both complicated
software testing and requirements management. The decision table allows testers
to examine all feasible combinations of requirements for testing and to
immediately discover any circumstances that were overlooked. True(T) and
False(F) values are used to signify the criteria.
WHAT IS DECISION
TABLE TESTING?:-
Decision table testing is a
type of software testing that examines how a system responds to various input
combinations. This is a methodical methodology in which the various input
combinations and the accompanying system behavior (Output) are tabulated.
That's why it's also known as a Cause-Effect table because it captures both
causes and effects for improved test coverage.
STRUCTURE OF THE
DECISION TABLE or COMPONENTS OF THE DECISION TABLE or PARTS OF THE DECISION
TABLE:-
(a) Condition Stub:- This is where all the input conditions or decision
rule(s) that influence the outcome are enumerated. For clarity, each condition
is listed in a separate row.
(b) Action Stub:- It comprises every potential response, or output,
that can happen according to the input conditions. These are also added to
separate rows, usually just under the conditions.
(c )Condition Entries:- These are
the actual values (such as Yes/No, True/False, or specific ranges) that each
condition can take for a particular rule. Each column represents one unique
rule or scenario.
(d) Action Entries:- This part of
the file specifies what actions should be performed for each rule. The
conditions are associated with the actions in the same column.
Decision Table
Example 1:-
Here is an example of a Loan Approval Decision Table.
|
Conditions |
Rule 1 |
Rule 2 |
Rule 3 |
Rule 4 |
|
Age > 18 |
Yes |
Yes |
No |
Yes |
|
Credit Score
> 700 |
Yes |
No |
Yes |
No |
|
Income > Rs.
50,000 |
Yes |
Yes |
Yes |
No |
|
Actions |
||||
|
Approve Loan |
X |
|||
|
Request
Guarantor |
X |
|||
|
Reject Loan |
X |
X |
(a) Conditions Stub:- The leftmost rows under Conditions (e.g., Age >
18, Credit Score > 700, Income > Rs.50,000) list all the input
conditions.
(b) Condition Entries:- The values under each rule column (Yes/No) show how
the conditions apply in that specific scenario.
(c ) Action Stub:- The rows under → Actions (e.g., Approve Loan, Request
Guarantor, Reject Loan) list all possible outcomes.
(d) Action Entries:- The Xs indicate the actions for each rule based on
the given condition values.
Example 2 :- How to Create a Login Screen Decision Base
Table
Let's make a login screen with
a decision table. A login screen with E-mail and Password Input boxes.
The condition is simple − The
user will be moved to the homepage if they give the right username and password.
An error warning will appear if any of the inputs are incorrect.
|
Conditions |
Rule 1 |
Rule 2 |
Rule 3 |
Rule 4 |
|
Username (T/F) |
F |
T |
F |
T |
|
Password (T/F) |
F |
F |
T |
T |
|
Output (E/H) |
E |
E |
E |
H |
Where :-
T - Make sure your login and
password are correct.
F - Incorrect login or password
E - An error message appears.
H - The home screen appears.
WHAT POSSIBLE ACTION
WILL COME
ü Case 1 − Both the username and password were
incorrect. An error message is displayed to the user.
ü Case 2 − The username and password were both right, however,
the password was incorrect. An error message is displayed to the user.
ü Case 3 − Although the username was incorrect, the
password was accurate. An error message is displayed to the user.
ü Case 4 − The user's username and password were both
accurate, and the user went to the homepage.
WE MAY GENERATE TWO SITUATIONS WHEN
CONVERTING THIS TO A TEST CASE.
ü Enter the right username and password and click Login;
the intended consequence is that the user will be sent to the homepage.
AND ONE MORE FROM THE
SITUATION BELOW.
ü If the user types in the invalid username and password
and then clicks Login, the user should receive an error message.
ü When you provide the proper username and incorrect
password and click Login, the user should see an error message.
ü If the user types the invalid username and password
and then clicks Login, the user should receive an error message.
TYPES OF DECISION TABLES:-
1. Limited
Decision Table:- A Limited Decision Table
is used when the conditions are simple and independent, typically with two
possible values (for example, True/False). It is the most basic form, offering
minimal complexity for straightforward decision-making scenarios.
Example: Login system where conditions are “Username
Valid” and “Password Correct.”
2. Extended
Decision Table:- An Extended Decision
Table handles more complex scenarios involving multiple conditions with various
alternatives and potential interdependencies. This type is used when the
decision logic is intricate and there are many possible combinations of
conditions.
Example: Loan approval system with conditions like
“Income,” “Credit Score,” and “Debt-to-Income Ratio.”
3. Condition-Action
Table:- A Condition-Action Table maps
conditions directly to actions, making it easier to visualize how each condition
triggers a specific outcome. It’s particularly useful for systems where
conditions have a clear, direct impact on actions.
4. Rule-Based
Decision Table:- A Rule-Based Decision
Table integrates multiple decision rules to handle complex conditions and actions.
It is suitable for systems with several interacting conditions and rules that
dictate outcomes.
Example: Insurance eligibility system based on “Age,”
“Driving Record,” and “Location.”
Example: Discount system where “Membership” and
“Purchase Total” determine the discount.
ADVANTAGES OF DECISION TABLES:-
(1). Clear Representation of Logic: One of the biggest advantages of decision tables is
that they make complex rules easy to understand. By laying out the conditions
and possible actions in a simple, visual format, they help everyone—developers,
testers, and stakeholders—see how different inputs lead to specific outputs.
This makes it much easier to spot errors in the decision logic.
(2). Thorough Test Coverage: Decision tables are great for ensuring that all
scenarios are tested. They help you list every possible combination of
conditions, which means you can create test cases that cover all possible
outcomes. This reduces the chances of missing edge cases or scenarios that
might break the system.
(3). Streamlining (rearrangement) Complex
Scenarios: When multiple conditions are
in play, managing all the combinations manually can get tricky. Decision tables
simplify this by organizing all possible input combinations and showing the
corresponding actions. This reduces complexity and helps testers easily design
comprehensive test cases without overlooking any condition.
(4). Automation-Friendly: Since decision tables follow a clear structure,
they’re easy to translate into automated tests. With automated testing, you can
quickly check whether the system behaves as expected across all conditions.
This can save a lot of time, especially for large-scale projects, and ensures
stability in testing.
(5). Better Communication Across Teams: Having a decision table is like having a shared map
for everyone involved in the project. It clearly outlines how the system is
supposed to behave, which helps ensure that developers, testers, and business
teams are all aligned. This clears up confusion and makes sure everyone is aligned.
DISADVANTAGES OF DECISION TABLES:-
(1) Scalability
Issues with Large Numbers of Conditions:- The
more conditions you have, the bigger and more complicated the decision table
becomes. With a large number of conditions, the table can grow quickly, leading
to an vast number of combinations to manage. It can also make it harder to keep
track of changes over time.
(2) Not
Ideal for Real-Time or Dynamic Decisions:- Decision
tables are great for static or well-defined rules, but they’re not the best fit
for real-time decision-making. If your system needs to make decisions based on
constantly changing or unpredictable data, decision tables can struggle to
handle that complexity.
(3) Hard
to Handle Interdependent Conditions:- Decision
tables are most effective when conditions are independent of one another. If
the outcome of one condition affects another, the table can become very
complicated or fail to capture all the necessary interactions. You might need
to use additional logic or methods to handle these interdependencies.
(4) Struggles
with Continuous Conditions:- Decision
tables work best with discrete conditions like Yes/No or specific values. When
you’re dealing with continuous or range-based data (for example, temperatures
or prices within a range), it can be tough to represent those conditions
accurately in a decision table, as there are too many possibilities to capture.
(5) Difficult
to Update in Large Systems:- In large,
evolving systems, decision tables can become a maintenance burden. As business rules
change, the table needs to be updated to reflect these changes. This can be
time-consuming, especially if the system involves many conditions that shift
over time.
SRS DOCUMENT IN SOFTWARE ENGINEERING:-
A software requirements specification (SRS) is a
detailed description of a software system to be developed with its functional
and non-functional requirements. The SRS is developed based the agreement
between customer and contractors. It may include the use cases of how user is
going to interact with software system. The software requirement specification
document consistent of all necessary requirements required for project
development. To develop the software system we should have clear understanding
of Software system. To achieve this we need to continuous communication with
customers to gather all requirements.
A good SRS defines the how Software System will
interact with all internal modules, hardware, communication with other programs
and human user interactions with wide range of real life scenarios. Using the
Software requirements specification (SRS) document on QA lead, managers creates
test plan. It is very important that testers must be cleared with every detail
specified in this document in order to avoid faults in test cases and its
expected results.
It is highly recommended to review or test SRS
documents before start writing test cases and making any plan for testing.
CHARACTERISTICS OF GOOD SRS:-
1. Correctness:- User review is used to provide the accuracy of
requirements stated in the SRS. SRS is said to be perfect if it covers all the
needs that are truly expected from the system.
2. Completeness:-
The SRS is complete if, and only if, it includes the following elements:
(a). All essential requirements, whether relating to
functionality, performance, design, constraints, attributes, or external
interfaces.
(b). Definition of their responses of the software to
all realizable classes of input data in all available categories of situations.
(c). Full labels and references to all figures, tables,
and diagrams in the SRS and definitions of all terms and units of measure.
3. Consistency:- The SRS is consistent if, and only if, no subset of
individual requirements described in its conflict. There are three types of
possible conflict in the SRS:
(1). The specified characteristics of real-world
objects may conflicts.
For example
(a) The format of an output report may be described in
one requirement as tabular but in another as textual.
(b) One condition may state that all lights shall be
green while another states that all lights shall be blue.
4. Unambiguousness:- SRS is unambiguous when every fixed requirement has
only one interpretation. This suggests that each element is uniquely
interpreted. In case there is a method used with multiple definitions, the
requirements report should determine the implications in the SRS so that it is
clear and simple to understand.
5. Modifiability:- SRS should be made as modifiable as likely and should
be capable of quickly obtain changes to the system to some extent.
Modifications should be perfectly indexed and cross-referenced.
6. Design
Independence:- There should be an option
to select from multiple design alternatives for the final system. More
specifically, the SRS should not contain any implementation details.
7. Testability:- An SRS should be written in such a method that it is
simple to generate test cases and test plans from the report.
STEPS TO CREATE A SOFTWARE REQUIREMENT
SPECIFICATION (SRS) DOCUMENT:-
STEP 1: Gather Preliminary Information:- In the initial stages of creating a Software
Requirement Specification (SRS) document, the first step involves gathering
preliminary information through a structured approach. This process begins with
understanding the scope of the project, which entails defining what is included
and excluded from the software development endeavor.
STEP 2: Define the Purpose and Objectives:- In the second step of creating a Software Requirement
Specification (SRS) document, it is essential to define the purpose and
objectives of the document clearly. This involves identifying the primary
objectives that the SRS aims to fulfill, which include serving as a blueprint
for both the development team and stakeholders.
STEP 3: Detailed Requirements Analysis:-
(a) Functional
Requirements:- Functional requirements
are specific behaviors or functions of the software system that outline what
actions the system must perform to support users or stakeholders.
(b) Non-functional
Requirements:- Non-functional
requirements describe criteria that govern the operation of the system,
focusing on aspects such as performance, usability, reliability, and security.
Unlike functional requirements, which directly relate to business functions,
non-functional requirements support the functionality of the system but do not
perform these functions themselves.
STEP 4:
Specify and Model Requirements:- In Step
4 of creating a Software Requirement Specification (SRS) document, the focus is
on specifying and modeling requirements with precision and clarity.
(a) Clear
Specification:- Clear specifications are
vital within the software development process, providing detailed and
unambiguous descriptions of software functionality, system behaviors, and
constraints.
(b) Use
Cases and Diagrams:- Use cases are
employed to represent user interactions, scenarios, and system responses,
aiding in visualizing requirements and identifying potential gaps or
redundancies.
(c ) Review
and Validation:- The process of reviewing
specified requirements and models with stakeholders, development teams, and
end-users is crucial for verifying accuracy, feasibility, and completeness.
These reviews ensure that requirements align with actual user needs and
business objectives, minimizing the risk of misunderstandings or
misinterpretations.
STEP 5: Finalize and Validate the SRS
Document:-
(a) Review
with Stakeholders:- It is essential to
engage all stakeholders in a final comprehensive review of the SRS document.
This ensures that the document fully captures and accurately represents the
software development requirements, encompassing both functional and
non-functional aspects.
(b) Incorporate
Feedback:- The process of incorporating
feedback from the stakeholder review into the SRS document is iterative and
dynamic. Given the evolving nature of software development requirements, it is
crucial for the SRS document to evolve based on stakeholder input.
(c ) Approval
and Sign-off:- Securing final approval
for the SRS document from key stakeholders, including project sponsors,
end-users, and development team leaders, is a critical step.
WHAT IS IEEE STANDARDS :- IEEE was formed when two institutes joined forces. In
1963, AIEE and IRE (AIEE, American Institute of Electrical Engineers, and IRE
stands for Institute of Radio Engineers) joined to form the Institute of
Electrical and Electronics Engineers
IEEE stands for Institute of
Electrical and Electronics Engineers. It is a professional association
with a nonprofit organization with its headquarter in New York in the United
States of America. It is composed of engineers, scientists, allied
professionals, advancing innovation and technological excellence for the
benefit of humanity. IEEE has its main
focus on the following disciplines, Computer Science, Electrical Engineering ,
Electronics Communication Engineering, Information Technology.
IEEE's main motive is to set industry standards and
assist students and working professionals in these fields. The IEEE also hosts
conferences and meetings. It also serves as a publishing platform for
researchers.
IEEE STANDARDS FOR SRS:-
IEEE SRS Standard is a set of guidelines provided by
the Institute of Electrical and Electronics Engineers (IEEE) to write a
Software Requirements Specification (SRS) document in a clear, complete,
correct, and standard format.
Important IEEE standard for SRS:- IEEE 830-1998 for
classic and most commonly tough SRS standard. In academics, IEEE 830–1998 is
most widely used,
IEEE Standard is Used for SRS (Uses /
Importance):-
ü Maintain uniform structure
ü Avoid ambiguity in requirements
ü Improve communication between stakeholders
ü Help in design, testing, and maintenance
ü Reduce development errors
ü Support legal and contractual clarity
IEEE SRS Standard Format
(Detailed):-
1. Introduction:- Explains why the software is being developed.
1.1 Purpose:- Defines the goal of
the SRS, Intended audience (developers, testers, users)
Example: - This document describes
the requirements for an Online Library Management System.
Define IEEE standards for SRS.
IEEE defines software requirements specification as, ‘a document that
clearly and
precisely describes each of the essential requirements (functions,
performance, design
constraints and quality attributes) of the software and the
external interfaces. Each
requirement is defined in such a way that its achievement can be
objectively verified
by a prescribed method, for example, inspection, demonstration,
analysis or test.’
Identify the responsibilities of a Software Project Manager?
Software project manager is the person who manages so
1.2 Scope:- Overall description of
the software, Benefits and objectives
Example:- The system will manage
book records, users, and issue/return operations.
1.3 Definitions, Acronyms,
Abbreviations, Explains technical terms
Example:- SRS – Software
Requirements Specification, UI – User Interface
2. Overall Description :- Gives a high-level view of the system.
Define IEEE standards for SRS.
IEEE defines software requirements specification as, ‘a document that
clearly and
precisely describes each of the essential requirements (functions,
performance, design
constraints and quality attributes) of the software an
2.1 Product Perspective:- Relationship with existing
systems, System architecture overview
Example:- The system is a web-based application
connected to a centralized database.
2.2 Product Functions:- Main features (no technical
detail)
Example:- User registration, Book search, Issue and
return books
3. Specific Requirements (MOST IMPORTANT SECTION)
This section explains exact system behavior.
3.1 Functional Requirements:- What the system must do
Example:- The system shall allow users to search books
by title., The system shall allow admin to add new books.
4. Appendices:- Additional information, Sample reports, Data
dictionary
ARCHITECTURAL DESIGN IN SOFTWARE
ENGINEERING:-
Architectural design in software engineering refers to
the process of defining the structure, components, modules, and relationships
of a software system to satisfy specified requirements. It is a crucial phase
in the software development life cycle where high-level system structures are
designed to ensure that the system meets its functional and nonfunctional
requirements.
The architectural design includes :-
(1) System
Decomposition:- Breaking down the system into smaller, manageable components or
modules. This helps in better organization and understanding of the system.
(2) Component
Identification:- Identifying the key
components or modules that will make up the system. These components are
designed to encapsulate specific functionalities and may interact with each
other to achieve the overall system goals.
(3) Interface
Design:- Defining the interfaces between
components, specifying how they will communicate with each other. This involves
deciding on data formats, communication protocols, and other interaction
details.
(4) Data
Design:- Designing the data structures
that will be used by the system, including databases, data storage, and data
flow within the system. This includes decisions on data organization, storage,
retrieval, and manipulation.
(5) Architectural
Patterns:- Choosing architectural patterns or styles that best suit the
requirements of the system. Common architectural patterns include
client-server, layered architecture, micro services, and more.
(6) Security
Design:- Incorporating security measures into the architecture to protect
against potential threats and weaknesses.
(7) Scalability
and Performance:- Ensuring that the architecture is scalable to accommodate
future growth and designing for optimal performance under expected workloads
(8) Maintainability
and Extensibility:- Designing the system in a way that makes it easy to
maintain and extend. This involves considering factors such as modularity, code
reusability, and flexibility.
COMPONENT LEVEL DESIGN:-
Component level design refers to the process of
breaking down a system into its constituent parts to better understand how they
interact and connect. In software engineering, it is the phase that focuses on
defining and developing the software components that will be used to build the
overall system architecture.
Component level design has two main goals:-
1. Identify the components that are needed to build the
system. This includes determining the boundaries of each component and how they
relate to one another.
2. Define the interfaces between components. This makes
the components loosely coupled and independent, allowing them to be developed
and tested separately before being integrated into the full system.
When designing components, software engineers
consider:-
1. Functionality:- What is the purpose of the component?
What features will it provide?
2. Data:- What data does the component need to operate?
What data does it produce? How will it interface with data from other
components?
3. Dependencies:- On what other components does this
component trust? How will those dependencies be handled?
4. Reusability:- Can this component be reused in other
systems? If so, how can its design be made more common?
5. Scalability:- How will this component handle increases
in load or volume? Can its performance be optimized?
Three views of component level design:-
(1) An
Object-Oriented View:- A component contains a set of collaborating classes.
Each class within a component has been fully elaborated to include all
attributes and operations that are relevant to its implementation. As
part of the design elaboration, all interfaces that enable the classes to
communicate and collaborate with other design classes must also be defined.
(2) The
Traditional View:- A component is viewed as a functional element (i.e., a
module) of a program that incorporates. The processing logic , The internal
data structures that are required to implement the processing logic, An
interface that enables the component to be invoked and data to be passed to it.
(3) Process-Related
view, Emphasis is placed on building systems from existing components
maintained in a library rather than creating each component from scratch.
USER INTERFACE DESIGN:-
The process of creating software programs' designs and
user experiences is known as user interface design. User interface design will
narrow its focus on how features are represented, buttons, menus, icons, and all other graphical
components that enable users to interact with the software.
User interface is the front-end application view to
which user interacts in order to use the software. User can manipulate and
control the software as well as hardware by means of user interface. Today,
user interface is found at almost every place where digital technology exists,
right from computers, mobile phones, cars, music players, airplanes, ships etc.
User interface is part of software and is designed such a way that it is
expected to provide the user insight of the software. UI provides fundamental
platform for human-computer interaction. UI can be graphical, text-based,
audio-video based, depending upon the underlying hardware and software
combination. UI can be hardware or software or a combination of both.
The software becomes more popular if its user
interface is:-
(1) Simple to use (2) Clear to understand (3) Attractive (4) Responsive in a short time
(5) Consistent on all interface screens
User Interface two types
(1) Command
Line Interface:- CLI provides a command prompt, the place where
the user types the command and feeds to the system. The user needs to remember
the syntax of command and its use. Earlier CLI were not programmed to handle
the user errors effectively. A command is a text-based reference to set of
instructions, which are expected to be executed by the system. There are
methods like macros, scripts that make it easy for the user to operate. CLI
uses less amount of computer resource as compared to GUI.
A text-based command line interface can have the
following elements:- Command Prompt, Cursor, Command.
(2) Graphical
User Interface:- Graphical User Interface
provides the user graphical means to interact with the system. GUI can be
combination of both hardware and software. Using GUI, user interprets the
software. Typically, GUI is more resource consuming than that of CLI. With
advancing technology, the programmers and designers create complex GUI designs
that work with more efficiency, accuracy and speed.
A GUI system has following elements such as:- Icons.
Tabs, Windows manipulation icons, Standard tools bar, Menu etc.
Top UI Design Tools:- Figma, Sketch, Adobe XD, InVision, Axure RP
User Interface Design Golden Rules:-
(1) Define
the interaction modes in such a way that does not force the user into
unnecessary or undesired actions:- The
user should be able to easily enter and exit the mode with little or no effort.
(2) Hide
technical internals from casual users:- The
user should not be aware of the internal technical details of the system. He
should interact with the interface just to do his work.
(3) Provide
for flexible interaction:- Different people will use different
interaction mechanisms, some might use keyboard commands, some might use mouse,
some might use touch screen, etc.
(4) Allow
user interaction to be interruptible and undoable:- When a user is doing a sequence of actions the user
must be able to interrupt the sequence to do some other work without losing the
work that had been done. The user should also be able to do undo operation.
(5) Design
for direct interaction with objects that appear on-screen:- The user should be able to use the objects and
manipulate the objects that are present on the screen to perform a necessary
task. By this, the user feels easy to control over the screen.
WEBAPP DESIGN:- A web application or web app is a software application
that can be accessible via a web browser or a web-enabled device, such as a
smartphone or tablet. It operates on a web server and anyone with an internet
connection can use it. Web applications have become an integral part of our
daily existence, and their importance will continue to grow beyond 2024.
Webapp design is the process of creating a website
application that delivers a seamless (whole) user experience (UX) and meets
users’ core needs with a clear, compelling user interface (UI). Web app design
plays an important role in development. It is the guide between the consumer
and the customer. Its task is to make a first impression on the user, to
anticipate their needs and to make use of the web page conveniently.
You have certainly used many web applications if you
are an Internet user. Airbnb, НubЅроt, Spotify, DoorDash, Canva are all web app
design examples. Web applications or web apps are interactive software
programs. Instead of computer-based programs running locally on the end user’s
machine, they run on a remote server. People shall access them via a web
browser with an Internet connection.
Actions such as using your laptop computer to check
your email, shop online, or access your bank accounts may involve web
applications with clean design. The web application design process is important
for building a web application. It focuses on interface elements and the look
and feel of a web app. The design stage includes many features.
Web app interface design in software engineering has
five main components:-
1. User Interface
2. Usability
3. Content
4. Creativity
5. Accessibility.
Each of them is important in your journey to build a
great web app where customers will become familiar with your services. You may
require hiring the best UI/UX designers for your web app design.
WEB APPLICATION DEVELOPMENT PROCESS:-
The web application development process involves
several phases.
1. Requirement Gathering and Analysis:
·
Understand the
project’s goals, target audience, and business requirements.
·
Collaborate with
stakeholders to gather detailed project requirements and expectations.
·
Define functional
and non-functional requirements for the web application.
2. Planning:-
·
Create a project
plan that outlines the scope, timeline, budget, resources, and milestones.
·
Determine the
technology stack, frameworks, and tools that will be used.
·
Plan the
application’s architecture, including data models, components, and
interactions.
3. Design:-
·
Design the user
interface (UI) and user experience (UX) of the web application.
·
Create
wireframes, prototypes, and mockups to visualize the layout and interactions.
·
Design database
schemas, data flows, and system diagrams.
4. Front-End Development:-
·
Develop the
client side of the web application using HTML, CSS, and JavaScript.
·
Implement the UI
design, including responsive layouts and interactive elements.
·
Integrate
front-end frameworks and libraries as needed.
5. Back-End Development:-
·
Develop the
server-side logic, business logic, and APIs using the chosen programming
language and framework (e.g., Python with Django or Flask, Node.js with
Express, Ruby on Rails, etc.).
·
Implement user
authentication, authorization, and security measures.
·
Create RESTful (Representational
State Transfer, It is a type of API (Application Programming Interface) that
allows communication between different systems over the internet. REST APIs
work by sending requests and receiving responses) or GraphQL (Graph Query
Language) APIs for communication between the front-end and back-end.
6. Database Development:
·
Design and create
the database schema based on the application’s data requirements.
·
Choose an
appropriate database management system (e.g., MySQL, PostgreSQL, MongoDB) and
set up the database.
·
Implement data
storage, retrieval, and manipulation operations.
7. Integration:-
Integrate third-party services, APIs, and libraries
that enhance the application’s functionality (e.g., payment gateways, social
media integration, geolocation services).
8. Testing:-
·
Conduct various
levels of testing, including unit testing, integration testing, and user
acceptance testing.
·
Test the
application’s functionality, performance, security, and compatibility across
different browsers and devices.
·
Identify and fix
bugs, errors, and inconsistencies.
9. Deployment:-
·
Deploy the web
application to a production environment, such as a web server, cloud platform,
or hosting service.
·
Configure server
settings, domain name, and security measures (SSL (Secure Sockets Layer, Sometimes
called digital certificates) / TLS (Transport Layer Security) certificates).
·
Set up monitoring
and error tracking tools to ensure the application’s stability.
10. Maintenance and Updates:-
·
Continuously
monitor the application’s performance, security, and user feedback.
·
Regularly update
and maintain the application, including bug fixes, security patches, and
feature enhancements.
·
Scale the
application as needed to accommodate increased user demand and traffic.
11. Documentation and Training:-
·
Create user
documentation, including user guides and tutorials, to help users navigate and
use the application effectively.
·
Provide training
and support to users, administrators, and other stakeholders as required.
12. Post-Launch Activities:-
·
Market and
promote the web application to attract users and drive engagement.
·
Gather user
feedback and analyze metrics to make informed decisions for future updates and
improvements.
WHAT IS THE DIFFERENCE BETWEEN WEB
APPLICATIONS AND WEBSITES?:-
|
Feature |
Website |
Web Application |
|
Purpose |
Primarily informational; static content |
Interactive; dynamic content and user tasks |
|
Interaction |
Limited interaction, mostly read-only |
High interaction; users can perform actions |
|
Complexity |
Generally simpler; basic navigation |
More complex; requires user input and processing |
|
Functionality |
Often consists of pages with text, images, and links |
Provides functionality like forms, user accounts,
and real-time updates |
|
Technology Suite |
HTML, CSS, and basic JavaScript |
More advanced technologies; often uses frameworks
and API |
|
User Interface |
Standardized; consistent layout across pages |
Customized; often tailored to user preferences and
tasks |
|
User Access |
Users visit to get information or read content |
Users engage to complete tasks or interact with
services |
|
Examples |
Blogs, news sites, company info pages |
Online banking, email services, productivity tools |
SUBMISSION OF SRS DOCUMENT FOR TEAM PROJECT:-
STEP 1:- Submission of SRS (Software Requirement Specification) Document means
formally presenting and handing over the finalized requirement document of a
software project to the guide, client, or evaluation committee. In a team project, the SRS is prepared
collaboratively and submitted after approval from all team members and
stakeholders. It acts as a contract between the development team and the
client.
STEP 2:- Purpose of Submitting an SRS Document
The main purposes are:
1. To clearly define what the software will do
2. To avoid misunderstanding
among team members
3. To get official
approval before development starts
4. To act as a reference
document during coding and testing
5. To help in project
evaluation and marking
STEP 3:- Who Submits the SRS in a Team
Project?
In a team project:-
1. The Team
Leader usually submits the SRS
2. All team members contribute to writing different
sections
3. The document contains:
4. Team name
5. Project title
6. Member names & roles
7. Guide/mentor name
STEP 4. Standard Steps for Submission of SRS
Document
Step 1: Requirement Gathering
1. Collect requirements from
2. Client
3. End users
4. Project guide
5. Discuss problems and expectations
Step 2: Requirement Analysis
1. Analyze requirements for:
2. Feasibility
3. Completeness
4. Clarity
5. Remove unnecessary or unclear requirements
Step 3: Divide Work among Team Members
Each member writes a section:
|
Team Member |
Responsibilities |
|
Member 1 (Deepak) |
Introduction and Overall Description |
|
Member 2 (Sushma) |
Functional Requirement |
|
Member 3 (Mohit) |
Non Functional Requirement |
|
Member 4 (Vishal) |
Diagram and Appendices |
Step 4: Prepare the SRS Document (IEEE
Format)
Typical SRS sections:
1. Title Page
2. Revision History
3. Table of Contents
4. Introduction
5. Overall Description
6. System Features
7. External Interface Requirements
8. Non-Functional Requirements
9. Constraints & Assumptions
10. Appendix ( It
holds detailed items like raw data, survey questions, interview transcripts,
large tables, charts, or complex procedures, adding depth without disrupting
the flow, and must be clearly labeled (e.g., Appendix A) and referenced in the
body of the report)
Step 5: Internal Review by Team
1. Team members review the document
2. Check:- Grammar, Consistency, Missing requirements, Make
corrections
Step 6: Approval from Guide / Client
1. Submit draft SRS to guide
2. Guide suggests modifications
3. Make changes and finalize the document
Step 7: Final Submission
1. Print or upload the SRS
2. Attach:- Cover page, Declaration, Signatures (if
required), Submit before the deadline
EXAMPLE: SRS SUBMISSION FOR A TEAM PROJECT
Project Title:- Online Food Ordering System
Team Members:
Deepak Kumar Jha:- Team Leader
Sandeep Nandi Singh:-
Developer
Sushma Behra :- Tester
Vishal Pradhan :- Documentation
Sample Content from SRS
STEP 1:-
. Introduction:- This document describes the requirements of the Online Food
Ordering System, which allows customers to order food online and track
delivery.
STEP 2:- Functional Requirements
1. User shall be able to register and login
2. User shall view restaurant menu
3. User shall place food orders
4. Admin shall manage food items
5. System shall generate order receipt
STEP 3. Non-Functional Requirements
1. System should respond within 2 seconds
2. Data should be secure
3. System should support 100 concurrent users
STEP 4. Constraints
1. Developed using Java and MySQL
2. Web-based application
3. Internet connection required
STEP 5.
Final Submission:
1. Submitted to: Project
Guide
2. Submission Date: 15-March-2026
3. Status: Approved
STEP 6. Importance of SRS Submission in Team
Projects
1. Ensures team
coordination
2. Helps in future
maintenance
3. Reduces project failure risk
4. Acts as legal
and academic proof
5. Used for marks
evaluation
7. Common Mistakes to Avoid
Unclear requirements, Copy-paste
from internet, Missing team member roles, No guide approval, Poor formatting
NOW THE UNIT 2
IS OVER
No comments:
Post a Comment
PLEASE DO LEAVE YOUR COMMENTS